During the past years, the interest in using mobile and landline/wireline computing devices in day-to-day communications has increased. Desktop computers, workstations, and other wireline computers currently allow users to communicate, for example, via e-mail, video conferencing, and instant messaging (IM). Mobile devices, for example, mobile telephones, handheld computers, personal digital assistants (PDAs), etc. also allow the users to communicate via e-mail, video conferencing, IM, etc. Mobile telephones have conventionally served as voice communication devices, but through technological advancements they have recently proved to be effective devices for communicating data, graphics, etc. Wireless and landline technologies continue to merge into a more unified communication system, as user demand for seamless communications across different platforms increases.
Many communication applications allow for real-time or near real-time communication that falls outside of the traditional voice communication associated with wireline and wireless telephone communications. Chat sessions, instant messaging, Short Message Service (SMS), video conferencing, are a few such communication vehicles. Many of these types of communications are expected to become increasingly popular, particularly in view of the proliferation of wireless devices and continual technological breakthroughs.
In order to implement such technologies, the “presence” technology is used to determine the location, willingness to communicate, and other parameters relating to real-time or near real-time communications. The presence technology generally refers to applications and services that facilitate location and identification of one or more endpoints to such communication links. For example, if a first user of a wireless, handheld device intends to initiate an IM session with a second IM user, presence services may be used to present the second user's willingness to receive IM messages. Presence services are an integral part of third generation (3G) wireless networks, and are intended to be employed across a wide variety of communication devices.
Presence information may be created at a presence server or an associated system. Presence information may be a status indicator that conveys the ability and willingness of a potential user to communicate with other users. The presence server may provide the presence information for distribution to other users (called watchers) to convey the availability of the user for communication. Presence information is used in many communication services, such as IM and recent implementations of voice over IP communications.
More specifically, a user client may publish a presence state to indicate its current communication status. This published state informs others that wish to contact the user of his availability and willingness to communicate. One use of presence is to display an indicator icon on IM clients, for example a choice of a graphic symbol with an easy-to-convey meaning, and a list of corresponding text descriptions of each of the states. This is similar to the “on-hook” or “off-hook” state of a fixed telephone.
Common states regarding the user's availability are “free for chat”, “busy”, etc. Such states exist in many variations across different modern instant messaging clients. However, the standards support a rich choice of additional presence attributes that may be used for presence information, such as user mood, location, or free text status.
Presence service is a network service which accepts, stores and distributes presence information. The presence service may be implemented as a single server or may have an internal structure involving multiple servers and proxies. There may be complex patterns of redirection and proxying while retaining logical connectivity to a single presence service. Also presence service may be implemented as direct communication among presentity and watchers, i.e., a server is not required.
A number of entities may be implemented in a presence service architecture. One of these entities is the presentity, which is an entity that provides presence information. Another entity is the presence server, which receives presence information from presentities. The watcher is an entity that is interested in the presence information.
The presence information (e.g., location, willingness to communicate at a certain time or with certain users, etc.) may be collected and utilized by presence servers, which may notify authorized “watchers” who are interested in certain presence information. Watcher applications may be implemented in wireline and/or wireless terminals to obtain presence information from the presence servers about other users. This may come in the form of a notification, issued to the watcher by the presence server.
Notifications to users/watchers that a targeted user/device has become available may be sent as complete or partial presence information. In other words, there are a number of different pieces of presence information that can be associated with the totality of the presence information. In a similar manner to the presence information and associated structure, there are location servers and location information regarding the users. The location information may include geographical location information.
In the IMS/SIP standard solutions SIP Publish is used to upload presence information to a presence server. Recently 3GPP has introduced Service Identification for communication services (CoSe) and IMS applications (IARI). Feature tags included in the SIP Register message includes the communication services, IMS applications and other capabilities that are available on the registering terminal. This information is equivalent to the service element information that is conveyed in the presence publication.
When a terminal is powered-on, it normally first sends a SIP Register message over an air interface to the registrar, e.g., home subscriber server (HSS), and thereafter sends a SIP Publish message to publish its available services to the Presence Server. In fact, there may be several publication messages sent by a UE over the air interface being powered on since many terminal implementations often require each application to send a separate SIP publish with service specific data.
The GSMA RCS industry initiative developed during the last few years to generate new applications for “always on” customers has not really taken off yet in the market. Recently a slightly new approach to RCS, called RCS-e, has been suggested which provides a subset of the functionality provided by RCS (with some extensions). One idea behind RCS-e is, for example, to provide a simplified RCS architecture where some functionality has been omitted, or rather made optional, in the hopes of gaining more rapid adoption in the market. For instance, presence information is optional in RCS-e.
One problem with the RCS-e approach when presence functionality has been removed is that the service capabilities of other users are no longer available. In order to address that problem, RSC-e proposes the use of SIP OPTIONS requests peer-to-peer instead to probe for the service capabilities of another user. A problem with this solution is that each client needs to send SIP OPTIONS requests to all users in the address book to check for the capabilities, which generates a huge amount of traffic in the network. Since the SIP OPTIONS request is sent on the UNI on both the originating and the terminating side it generates traffic also on the RAN as well as contributing to the battery drain on the handsets.
One solution to this problem is for client devices to include all of their service capabilities as feature tags when they register with the communication system, so that the Capability application server (AS) receives them in the 3rd Party Register request sent from the IMS Core Node to the Capability AS. However, it may be the case that the client will not include tags for all services that the client supports, which makes it difficult for the server to provide the correct capabilities back to a requestor. For instance, the client might include an ICSI for OMA IM but it won't be possible then to distinguish between whether that client, for example, has Chat and/or File Transfer service capabilities.
Accordingly, it would be desirable to provide devices, systems and methods for enabling capability discovery of client devices in such systems that avoid the afore-described problems and drawbacks.